#+TITLE: To do
#+AUTHOR: Zelphir Kaltstahl
#+EMAIL: zelphirkaltstahl@posteo.de
#+STARTUP: content indent align inlineimages hideblocks entitiesplain nologdone nologreschedule nologredeadline nologrefile
#+TODO: TODO INPROGRESS | DONE
#+DATE: [2022-01-21 Fri]
#+LANGUAGE: English
#+PRIORITIES: A E E


* TODO Tasks [0/5]

** TODO Serving static files [0/1]

*** TODO Use sendfile

Currently the implementation uses bytevector procedures to read static files and create responses with their content. Probably Guile's ~sendfile~ (see [[https://www.gnu.org/software/guile/manual/html_node/File-System.html][File-System]] in the Guile manual) is a more performant way of serving static files.

** TODO Handle keyboard interrupts

Keyboard interrupt (C-c) are not yet handled in a way that cleanly shuts down the server.

** TODO Unify module system usage

The various modules use different module systems. They should only use one module system.

** TODO Proper file reading [0/1]

Use exception handling instead of asking whether a file exists and then continuing to read the file without exception handling.

Reason: There is a chance that a file could be deleted immediately after an existence check and before the rest of the logic that depends on the file existing is executed.

*** TODO Reading big files

Check out [[https://hg.sr.ht/~arnebab/wispserve/browse/wispserve/serve.w?rev=4541f36df0b0#L411]], which deals with reading big files. It might be that simply reading whole files as bytevectors will run into problems when reading huge files. Also: What about using ~sendfile~ instead?

** TODO fslib [0/3]

*** TODO Redundant special characters checks

No need to check, whether a path has any special parts in it, because the file procedures of Guile do not interpret them in any special way as Bash would do anyway.

Only need to make sure, that a path is a subpath of the static directory.

*** TODO Implement subpath?

Implement ~subpath?~ as described in [[https://tools.ietf.org/html/rfc3986#section-5]].

*** TODO Naming

Think about different naming for path functions. Apparently "path" is understood as list of "things leading to directories" in a string in the GNU ecosystem. However, "file" seems still unfitting to use for simply everything. Perhaps there is a better name.
